miércoles, 2 de febrero de 2011

Instalar Apache 2.2 en GNU\Linux Fedora 14 con SELinux activado

Vamos a instalar el servidor Apache 2.2 en Fedora 14 actualizada a día 2 de Febrero de 2011. Para ello vamos a tener que configurar diferentes aspectos del sistema.

Instalación de los paquetes de Apache 2.2 y módulos

Para instalar Apache 2.2.X vamos a usar yum.

$ yum list httpd httpd-tools php php-mysql php-pecl-mongo pymongo python-asyncmongo mod_python mod_perl mod_ssl 

Complementos cargados:langpacks, presto, refresh-packagekit
Adding es_ES to language list

Paquetes instalados
httpd.i686                                                                       2.2.17-1.fc14                                                           @updates
httpd-tools.i686                                                                 2.2.17-1.fc14                                                           @updates

Paquetes disponibles
mod_perl.i686                                                                    2.0.4-11.fc14                                                           fedora  
mod_python.i686                                                                  3.3.1-14.fc14                                                           updates 
mod_ssl.i686                                                                     1:2.2.17-1.fc14                                                         updates 
php.i686                                                                         5.3.5-1.fc14                                                            updates 
php-mysql.i686                                                                   5.3.5-1.fc14                                                            updates 
php-pecl-mongo.i686                                                              1.0.10-4.fc14                                                           updates 
pymongo.i686                                                                     1.9-4.fc14                                                              updates 
python-asyncmongo.noarch                                                         0.1.2-1.fc14                                                            updates

Vemos que ya tenemos instalado apache 2.2.17, así que solo se instalarán los demás paquetes

$ su -c "yum -y install httpd httpd-tools php php-mysql php-pecl-mongo pymongo python-asyncmongo mod_python mod_perl mod_ssl"

Con esto instalaremos el servidor web y el soporte para php, python, servidor web seguro (ssl), perl, servidor de BBDD MySQL y MongoDB (base de datos orientada a documentos, noSQL) Además se instalarán unas cuantas dependencias.

SELinux

SELinux es un sistema de políticas de seguridad de acceso que usa Fedora, RedHat, CentOS para habilitar o deshabilitar diferentes características del sistema. Se puede administrar de forma gráfica con policycoreutils-gui, system-config-selinux o por línea de comandos. Nosotros lo haremos por línea de comandos.

También podríamos deshabilitar SELinux mediante

$ su -c "vim /etc/sysconfig/selinux"

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.

SELINUX=disable

Pero nosotros lo vamos a dejar como está para tener seguridad, aunque si tenéis problemas podéis deshabilitarlo.

Para ver las políticas de seguridad aplicadas al servidor apache vemos los siguientes comandos (podemos ver la descripción de las políticas con man httpd_selinux, aunque no están todas descritas). Cada política es un booleano, puede valer 1 (encendido, on) o 0 (apagado, off)

$ getsebool -a | grep httpd

allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
...

aunque es mejor usar semanage para ver la política y la descripción.

$ su -c "semanage boolean -l | grep httpd"
 
httpd_can_network_relay        -> apagado Allow httpd to act as a relay
httpd_can_network_connect_db   -> apagado Allow HTTPD scripts and modules to connect to databases over the network.
httpd_use_gpg                  -> apagado Allow httpd to run gpg in gpg-web domain
httpd_enable_cgi               -> encendido Allow httpd to execute cgi scripts
allow_httpd_mod_auth_pam       -> apagado Allow Apache to use mod_auth_pam
allow_httpd_anon_write         -> apagado Allow Apache to modify public files used for public file transfer services. Directories/Files must be labeled public_content_rw_t.
httpd_enable_homedirs          -> apagado Allow httpd to read home directories
allow_httpd_sys_script_anon_write -> apagado Allow apache scripts to write to public content.  Directories/Files must be labeled public_rw_content_t.
httpd_dbus_avahi               -> encendido Allow Apache to communicate with avahi service via dbus
httpd_use_cifs                 -> apagado Allow httpd to access cifs file systems
httpd_unified                  -> apagado Unify HTTPD handling of all content files.
httpd_builtin_scripting        -> encendido Allow httpd to use built in scripting (usually php)
httpd_can_network_connect      -> apagado Allow HTTPD scripts and modules to connect to the network using any TCP port.
httpd_tty_comm                 -> encendido Unify HTTPD to communicate with the terminal. Needed for entering the passphrase for certificates at the terminal.
httpd_read_user_content        -> apagado Allow httpd to read user content
httpd_use_nfs                  -> apagado Allow httpd to access nfs file systems
httpd_tmp_exec                 -> apagado Allow Apache to execute tmp content.
httpd_execmem                  -> apagado Allow httpd scripts and modules execmem/execstack
httpd_can_sendmail             -> apagado Allow http daemon to send mail
httpd_can_check_spam           -> apagado Allow http daemon to check spam
allow_httpd_mod_auth_ntlm_winbind -> apagado Allow Apache to use mod_auth_ntlm_winbind
httpd_can_network_memcache     -> apagado Allow httpd to connect to memcache server
httpd_can_network_connect_cobbler -> apagado Allow HTTPD scripts and modules to connect to cobbler over the network.
httpd_ssi_exec                 -> apagado Allow HTTPD to run SSI executables in the same domain as system CGI scripts.
httpd_enable_ftp_server        -> apagado Allow httpd to act as a FTP server by listening on the ftp port.
httpd_setrlimit                -> apagado Allow httpd daemon to change system limits

Para modificar una política de seguridad debemos usar el comando setsebool -P política on|off. La P es para que sea permanente, y no temporal hasta el reinicio del sistema.

Para activar que desde apache se puedan enviar correos electrónicos hacemos lo siguiente

$ su -c "setsebool -P httpd_can_sendmail on"
 
$ su -c "semanage boolean -l | grep httpd | grep encendido"

httpd_enable_cgi               -> encendido Allow httpd to execute cgi scripts
httpd_dbus_avahi               -> encendido Allow Apache to communicate with avahi service via dbus
httpd_builtin_scripting        -> encendido Allow httpd to use built in scripting (usually php)
httpd_tty_comm                 -> encendido Unify HTTPD to communicate with the terminal. Needed for entering the passphrase for certificates at the terminal.
httpd_can_sendmail             -> encendido Allow http daemon to send mail

Como vemos se ha activado correctamente (tarda un poquito en activarse) Activamos también las siguientes políticas, en shell de root.

# setsebool -P httpd_can_network_connect_db=1 httpd_can_network_connect=1 httpd_can_network_memcache=1 httpd_ssi_exec=1

Como vemos las he activado a la vez con esa nomenclatura. Esto permite a apache conectar a la red, y a bases de datos y memcache en la red, ejecutar lenguaje SSI.

La directiva httpd_builtin_scripting sirve para que se puedan ejecutar scripts PHP, python, etc.

Otra cosa importante es el contexto de los ficheros y directorios. Debemos agregar los ficheros y directorios que vaya a usar apache (como directorios que vayan a cargarse en el servidor con htmls y demás) a los contextos apropiados. Por ejemplo, vemos que el directorio que contiene los ficheros que sirve apache 2.2 /var/www/html tiene un tipo de contenido httpd_sys_content_t que permite que apache lo lea usando SElinux.

# ls -Z /var/www/
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 manual

Vemos como los cgi tienen otro tipo de contexto, httpd_sys_script_exec_t y hay contextos para muchos servicios (samba/cifs, nfs, etc)

Si queremos añadir otros directorios fuera del document root de apache y que sean leídos por apache 2.2 para publicar contenidos, debemos usar el comando chcon (change context) para esos directorios o ficheros. Si creamos un directorio o fichero dentro de un directorio que ya tiene un contexto, este lo hereda. Con -R hacemos que el comando chcon sea recursivo.

# mkdir /var/www/nuevodir
# ls -Z /var/www/
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 manual
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 nuevodir

# mkdir /root/nuevodirwww
# ls -Z /root
...
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 nuevodirwww

# chcon -R -t httpd_sys_content_t /root/nuevodirwww
# ls -Z /root
-rw-------. root root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 nuevodirwww

Vemos que en los dos directorios creados hemos cambiado el contexto. El primero se cambia automáticamente al crearse dentro de un directorio del que hereda el contexto, mientras que el segundo lo cambiamos nosotros manualmente. Ahora podremos usar ambos como directorios que puede usar apache para publicar contenidos.

Si hemos cambiado un tipo de contexto podemos restaurarlo a su tipo de contexto por defecto con restorecon.

# restorecon -R -v /root/nuevodirwww
restorecon reset /root/nuevodirwww context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:admin_home_t:s0
[root@fed1400 www]# ls -Z /root
...
drwxr-xr-x. root root system_u:object_r:admin_home_t:s0 nuevodirwww

Además, también podemos montar un sistema de ficheros completo con un contexto definido. En este caso no podremos usar chcon en los ficheros que se creen en el, solo se permiten ficheros de ese contexto. Por ejemplo si exportamos un nfs para que contenga ficheros web y lo montamos así

# mount miservidor:/export/www /mnt/www -o context="system_u:object_r:httpd_sys_content_t:s0"

Esto hace que montemos un directorio exportado por un servidor nfs en el directorio local /mnt/www y que se monte, en vez de con el contexto de nfs_t por defecto, con el tipo de contexto httpd_sys_content_t y así, podremos usar el directorio como document root de apache /mnt/www, por ejemplo.

Por último, podemos ver los contextos que existen en el directorio /etc/selinux/targeted/contexts. Como vemos hay muchísimos.

Gestión del servicio

Para administrar servicios disponemos del comando service y para iniciar un servicio en los diferentes niveles de inicio en el arranque disponemos de chkconfig.

Hacemos que apache se arranque o apage en los niveles de inicio por defecto. Ahora al arrancar se iniciará con el sistema de forma automática.

$ chkconfig --list httpd
httpd           0:desactivado   1:desactivado   2:desactivado   3:desactivado   4:desactivado   5:desactivado   6:desactivado

$ su -c "chkconfig httpd on"

$ chkconfig --list httpd
httpd           0:desactivado   1:desactivado   2:activo        3:activo        4:activo        5:activo        6:desactivado

Para administrar https podemos usar service con varias opciones:

Para ver si está iniciado
$ su -c "service --status-all | grep httpd"
httpd is stopped

Miramos si el archivo de configuración es correcto antes de iniciarlo. Siempre deberíamos comprobar esto después de modificar el archivo de configuración de apache.

$ service httpd configtest
httpd: Could not reliably determine the server's fully qualified domain name, using ::1 for ServerName
Syntax OK

La sintaxis está correcta pero da la advertencia de que no hemos dado un nombre de servidor cualificado.

Iniciamos el servicio apache
$ su -c "service httpd start"
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using ::1 for ServerName   [  OK  ]

$ su -c "service --status-all | grep httpd"
httpd (pid  5394) is running...

Para reiniciar el servicio apache tenemos varias formas, entre ellas:

  • restart: Reinicia el servicio y se pierden las conexiones actuales de los clientes. Se usa cuando hay que activar un modulo nuevo que hemos instalado, por ejemplo, python, proxy, php...
  • reload: Solo recarga el archivo de configuración sin reiniciar el servicio. Se usa el nuevo fichero de configuración. Las conexiones no se pierden pero si que hay cortes en las peticiones que estén siendo procesadas como el repintado de la pantalla del navegador que se puede quedar a la mitad o que de algún error, cosas así.
  • graceful: igual que reload pero no pierde las peticiones que están siendo procesadas aunque, las peticiones, siguen usando el antiguo fichero de configuración, no el nuevo.

Por ejemplo, para reiniciar apache

$ su -c "service httpd start"
Stopping httpd:                                            [  OK  ]
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using ::1 for ServerName                                   [  OK  ]

Configuración del firewall

Vamos a abrir los puertos 80 y 443 para http y https.

# vim /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
# Abrimos puertos 80 y 443
-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 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Reiniciamos iptables y mostramos las reglas aplicadas. También podemos usar system-config-firewall. Si lo usamos, lo que hayamos puesto en el anterior fichero será sobreescrito por la configuración gráfica. Si podemos usar la configuración gráfica siempre mejor, pero lo muestro en línea de comandos. Ya sabeis que si habéis iniciado sesión ssh con la opción -X podréis ejecutar en la consola # system-config-firewall & y saldrán las pantallas en vuestro ordenador remoto, como hemos visto en otros artículos como el de kickstart.

# service iptables restart
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules:                         [  OK  ]

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https 
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Antes de hacer esto, poner la ip del host donde estamos instalando apache en el navegador web daría error, rechazaría la conexión. Ahora nos sale la pantalla de bienvenida tanto en http como https aceptando el certificado.


En la siguiente entrega veremos la configuración de Apache.
Related Posts with Thumbnails