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
...
192.168.1.10 server server.local
192.168.1.11 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
ALL: ALL
[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
...
MOUNTD_PORT="4002"
STATD_PORT="4003"
LOCKD_TCPPORT="4004"
LOCKD_UDPPORT="4004"
RQUOTAD_PORT="4005"
[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
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
: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
COMMIT
[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
Enforcing
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
.png)
