Jul 29, 2012

Remote log server via HTTP (I)

When you have a network with multiple servers which can be accessed by several people, for example in order to take a look at their log files, it is desirable to centralize this task on a single machine which is the common point of access for all. In this way, you will improve aspects related to the security of your infrastructure:

  • Those people will not directly log on the servers.
  • It will be possible to create a copy of the most important log files in real time.

The schema that I am going to follow so as to develop this series of articles is based on a couple of Linux servers (CentOS 6.3). The first computer, client, will be the machine which will export their log files, either by means of NFS or Samba. And the second one, server, will be the machine will import those log files and will put forward them via HTTP.

In addition, the log server will carry out a backup each five minutes of the log files through rsync. The aim of backing up is to be able to have a copy of the log files in case of one of the servers was messed up and it was impossible to reach it.

NFS is a protocol belonging to the application level and used to share volumes between several computers within a network. In return, Samba is an implementation from the SMB (Server Message Block) protocol for Linux machines, renamed to CIFS (Common Internet File System) later, which allows to share resources (directories, printers, etc.) between different computers, authenticate connections to Windows domains, provide Windows Internet Naming Service (WINS), work as PDC (Primary Domain Controller), and so on.

Using either protocol has its advantages and disadvantages. For this reason, it will be exposed in this articles both protocols. Basically, NFS does not use users and passwords like Samba, but that the only way to perform an access control is through IP addresses or host names. On the other hand, in order to share files across a local area network, NFS can be enough.

First of all, let's register the names of all implicated nodes inside the file /etc/hosts.

[... ~]# cat /etc/hosts
... server  server.local client  client.local

In this first article, we are going to set out by configuring NFS in the client machine. You will have to make sure to grant read permissions for all users to those elements you want to export.

[root@client ~]# chmod -R o+r /var/log/

Now you have to set up NFS in order to make public the previous directory. Afterwards, the NFS daemon will have to be started and enabled.

[root@client ~]# cat /etc/exports
/var/log/       server.local(ro,sync,root_squash)

[root@client ~]# service nfs restart ; chkconfig nfs on

As you can see, by means of the file /etc/exports it has been indicated that the /var/log directory just will be able to be mounted by server.local in read-only mode (ro). Furthermore, requests only will be replied after the changes have been committed to stable storage (sync) and those of them which came from root, will be mapped to anonymous (root_squash).

In order to secure this server, you can begin with TCP wrappers, thus you have to allow both portmap (converts RPC program numbers into Internet port numbers) and mountd (answers a client request to mount a file system) services only for the IP address where they will be listening to.

[root@client ~]# cat /etc/hosts.deny

[root@client ~]# cat /etc/hosts.allow
sshd: ALL
portmap: server.local
rpcbind: server.local
mountd: server.local

So as to the NFS service can be protected by iptables, you will have to add the following lines to the /etc/sysconfig/nfs file (by default, NFS establishes the link through a random port).

[root@client ~]# cat /etc/sysconfig/nfs

[root@client ~]# service nfs restart

It happens that in NFSv4, the only ports that you need to open are 2049 TCP and 111 UDP. But in order to protect NFSv3 and NFSv2 by a firewall, as well as to be able to use the showmount command, you need to open the previous ports.

Now you have to add the corresponding rules to the iptables configuration file.

[root@client ~]# cat /etc/sysconfig/iptables
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport ssh -j ACCEPT
-A RH-Firewall-1-INPUT -s server.local -p tcp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s server.local -p udp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s server.local -p tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -s server.local -p udp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -s server.local -p tcp --dport 4002:4005 -j ACCEPT
-A RH-Firewall-1-INPUT -s server.local -p udp --dport 4002:4005 -j ACCEPT
-A RH-Firewall-1-INPUT -j LOG
-A RH-Firewall-1-INPUT -j REJECT

[root@client ~]# service iptables restart

[root@client ~]# chkconfig iptables on

Also remember that it is really important to have SELinux enabled and running in enforcing mode.

[root@s1 ~]# getenforce

And finally, let's try out the directories exported by client from the server machine.

[root@server ~]# showmount -e client.local
Export list for client.local:
/var/log server

Jul 21, 2012

Hooking up Thunderbird to Exchange via DavMail (III)

Let's ending up the series of articles about Hooking up Thunderbird to Exchange via DavMail (I, II). Through this final part, I am going to configure Lightning as a calendar connected to Microsoft Exchange. We are talking about an extension that adds calendar functionality to Thunderbird, and allows you to create your own calendars, subscribe to another calendars and manage your own schedule.

First of all, you have to download the add-on related to this feature. In my case for example, I am using Thunderbird 14.0 on Ubuntu 12.04. Thereby, I have had to grab Lightning 1.6. Don't worry about future Thunderbird updates, since you will automatically be informed about this issue and will have the option to upgrade to a supported version of Lightning.

After downloading Lightning, go to Tools, Add-ons and select Install Add-on From File. Choose the file previously downloaded and restart Thunderbird. Now you are ready to add and configure a new calendar. For this purpose, go to File, New, Calendar and fulfil the wizard. In the first screen, pick out On the Network, and in this way your calendar will be able to be stored on a server so as to access it remotely.

In the next screen, select CalDAV as Format and for Location, type the URL http://localhost:1080/users/ followed by your email address.

And finally, you can give a name to your calendar. After this step, a pop-up will request you about a username and password for your account.

Lastly, your new calendar will be correctly hooked up to Microsoft Exchange and prepared to be used from now on.

Jul 9, 2012

Hooking up Thunderbird to Exchange via DavMail (II)

This is the second part of the article about Hooking up Thunderbird to Exchange via DavMail (I). During the first one, it was put forward how to configure DavMail so as to work as gateway between Thunderbird and Microsoft Exchange. The next step is to set up Thunderbird in order it to point to the new services that remain listening through DavMail.

You can appreciate by means of the following figure that, the credentials for the email account and the address and port where the services started in DavMail are running, have been set.

And finally, you can add a LDAP directory to be able to look up people from your company. For this purpose, open the Address Book and go to File, New, LDAP Directory, and fill in the information required for the directory server.

If you want Thunderbird to automatically search for possible addresses (in the LDAP server previously configured) when you are composing an email and typing the recipient, enable the next option in Thunderbird Preferences.