Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Guía configuración y optimización Apache (MPM, suExec, http2, modsecurity)

domingo, 17 de enero de 2021 | Publicado por el-brujo | Editar entrada

Esta guía se compondrá de tres partes (series) sobre la correcta instalación de LAMP (Linux, Apache, MySQL, PHP). Optimizar y configuración avanzada  de Apache (MPM, diferencias 2.2 y 2.4, http2, mod_security (WAF) , Apache suExec, migración a nginx. Segunda parte: Optimizar y configurar PHPFPM (módulo PHP) y opciones de seguridad en PHP y la tercera parte configuración y optimización y seguridad en MySQL (MariaDB, Percona) (MyISAM vs InnoDB, log binario, copias de seguridad mysqldump, variables key_buffer_size (MyISAM), innodb_buffer_pool_size para InnoDB  etc)



 
Esta guía se compondrá de tres partes (series) sobre la correcta instalación de LAMP (Linux, Apache, MySQL, PHP)
En futuras entradas hablaremos en profundidad de nginx, un servidor web muy superior a Apache en cuanto a rendimiento.

Nginx es un proxy invertido con capacidades de web server , que como es obvio tiene la capacidad de poner a disposición de una red (o internet) sitios web tanto estáticos como dinámicos. Hoy día es el segundo servidor web más extendido en uso y ganando terreno a su principal competencia, Apache, día tras día.

Otra cifra importante es la cantidad de tráfico que es capaz de gestionar , dejando prácticamente en ridículo a Apache cuando los enfrentamos en una gráfica con las solicitudes a las que es capaz de atender. 

Esto en gran parte es gracias a su caché de solicitudes , ya que mientas que un servidor Apache denegará peticiones a sitios web que aloje cuando su servidor esté saturado, Nginx almacenará esas solicitudes y las seguirá atendiendo sin mermar la capacidad ni interrumpir el funcionamiento del hosting . 

Configuración Avanzada y optimización de Apache

Opciones básicas seguridad (ocultar versión Apache completa)

ServerTokens Prod
ServerSignature Off
TraceEnable Off
No permitir listado de directorios:

<Directory /var/www/html>
    Options –Indexes
</directory>

Header always unset X-Powered-By

 Algunas opciones recomendadas para optimizar en el fichero httpd.conf

# ya es off por defecto
#HostnameLookups Off
# ok por defecto es 5
# KeepAliveTimeout 5
# por defecto ya es on correcto
#KeepAlive On
#  config ok por defecto es 100
MaxKeepAliveRequests 500

Habilitar HTTP2


HTTP / 2 acelera la carga de la página. HTTP/2 es la evolución del protocolo de la capa de aplicación con más éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red. No cambia la característica fundamental de HTTP, la semántica. Todavía hay olicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.


  • HTTP/2 es un protocolo binario, al contrario que HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea legible (por ejemplo capturando el tráfico de red) mientras que para HTTP/2 no. Más información en el FAQ oficial ¿Por qué es binario HTTP/2?
  • h2 es HTTP/2 sobre TLS (negociación de protocolo a través de ALPN).
  • h2c es HTTP/2 sobre TCP.
  • HTTP/2 es capaz de llevar múltiples streams de datos sobre la misma conexión TCP, evitando la clásica solicitud lenta "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones TCP para cada solicitud/respuesta (KeepAlive parcheó el problema en HTTP 1.1 pero no lo resolvió completamente). 

Para habiltiar http2 es necesario cargar  el módulo en httpd.conf

LoadModule http2_module modules/mod_http2.so

La segunda directiva que necesita añadir a la configuración de su servidor (vhost) es:

# enable HTTP/2, if available

Protocols h2 http/1.1

Esto permite h2, la variante segura, para ser el protocolo preferido de las conexiones en su servidor. Cuando quiera habilitar todas las variantes de HTTP/2, entonces simplemente configure:

Protocols h2 h2c http/1.1
Recuerda que si utilizas CloudFlare no es necesario habilitar HTTP2 ya que todas las peticiones que realizar CloudFlare al servidor de origen son HTTP 1.1

Aunque http2 es "compatible" con MPM prefork pero con limitaciones severas. Se recomienda utilizar worker o event para http2

Apache MPM (Módulos de MultiProcesamiento)

Apache 2.4 tiene 3 módulos disponibles:

  • 1) prefork  --> Por defecto en Apache 2.2 y obligatorio para mod_php (DSO)
  • 2) worker
  • 3) event --> una evolución de Worker, ideal para PHP-FPM. Perfeccionada en 2.4.x
 En el fichero
 
/etc/httpd/conf.modules.d/00-mpm.conf 

Podemos ver que módulo mpm estamos usando: 


1)No usa el mpm prefork MPM (está comentado)
 

#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

Usa 3)  Event


LoadModule mpm_event_module modules/mod_mpm_event.so


Trucos configuración


  • Establece MinSpareThreads en un 50% de MaxRequestWorkers.
  • Haz coincidir tanto MinSpareThreads como MaxSpareThreads con MaxRequestWorkers. Requisitos: asegúrate de que haya suficiente RAM en el servidor para ejecutar todos los MaxRequestWorkers a la vez.
  • En los MPM basados en Worker: ServerLimit, ThreadsPerChild y MaxRequestWorkers están intrínsecamente vinculados entre sí. Es fundamental comprender el papel de cada uno y cómo el cambio de uno afecta a los demás. Las siguientes directivas gobiernan el ajuste fino de las capacidades de manejo de subprocesos de los servidores web Apache.

Comprueba  desde el registro de errors servidor web, encontramos que no haya mensajes relacionados con "la configuración de MaxRequestWorkers alcanzada", por lo que parece que el problema está relacionado con nuestra configuración predeterminada de Apache

reached MaxRequestWorkers setting


Cuando se utilizan controladores de código externos como Mod_fcgid, PHP-FPM o mod_lsapi, es necesario establecer MaxConnectionsPerChild en 0 (ilimitado), al hacerlo, se evita que las páginas de error periódicas causadas por Apache terminen los hilos de manera prematura.


Config por defecto de los 3 módulos:

1) MPM Prefork


Por  defecto:
<IfModule prefork.c>
        StartServers              5
        MinSpareServers           5
        MaxSpareServers           10
        MaxRequestWorkers         150
        MaxConnectionsPerChild    0
</IfModule>

Tuning según Linode 
1)
 
<IfModule mpm_prefork_module>
       StartServers              4
       MinSpareServers          20
       MaxSpareServers          40
       MaxRequestWorkers       200
       MaxConnectionsPerChild 4500
</IfModule>


Tuning según  ionos 1)
<IfModule prefork.c>
   StartServers        5
   MinSpareServers     5
   MaxSpareServers     10
   MaxClients          150
   MaxRequestsPerChild 3000
</IfModule>


Tuning según alibaba 1)
<IfModule MODULE_NAME>
    StartServers             4
    MinSpareServers          20
    MaxSpareServers          40
    MaxClients               200
    MaxRequestsPerChild      4000
</IfModule>


Tuning según techrepublic.com 1)
StartServers                          4
MinSpareServers                  3
MaxSpareServers                 40
MaxRequestWorkers             200
MaxConnectionsPerChild      10000


Observaciones:
 
MinSpareServer number, more processes are created at the rate of one per second on Apache 2.2 or lower. With Apache 2.4, this rate increases exponentially starting with 1 and ending with 32 children spawned per second.
MaxRequestWorkers --> antes MaxClients (Apache 2.3.13 or lower), this parameter indicates the maximum amount of requests that can be served simultaneously, with any number going past the limit being queued. The size of the queue is based on the ListenBacklog directive. If MaxRequestWorkers is set too low, connections sent to the queue eventually time-out; however, if set too high, it causes the memory to start swapping. If this value is increased past 256, the ServerLimit value must also be increased

MaxConnectionsPerChild --> antes MaxRequestsPerChild

2) MPM Worker

Configuración por defecto

<IfModule worker.c>
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 0
</IfModule>

3) MPM Event





Por Defecto:

<IfModule event.c>
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25

# por defecto es 256 https://httpd.apache.org/
# cambiar por algo si es 150 mas grande si es > 256 ServerLimit debe aumentarse
MaxRequestWorkers 150
MaxConnectionsPerChild 0
</IfModule>


# Parecen valores muy muy altos
 
<IfModule mpm_event_module>
        ServerLimit              2800
        StartServers             4
        MinSpareThreads          25
        MaxSpareThreads          75
        ThreadLimit              64
        ThreadsPerChild          25
        MaxRequestWorkers        2800
        MaxConnectionsPerChild   1000
</IfModule>

Herramientas benchmark y optimización Apache 

Apache2Buddy


Apache2Buddy es una gran herramienta que verifica la configuración y el rendimiento de su servidor y hace un informe y sugerencias basadas en la información que recopila. Calcula MaxRequestWorkers en la RAM restante, no en la RAM total instalada.

Puede ejecutar Apache2Buddy mediante el siguiente comando:

curl -sL https://raw.githubusercontent.com/richardforth/apache2buddy/master/apache2buddy.pl | perl

ApacheBench (ab)


La herramienta ApacheBench viene incluida con la distribución fuente estándar de Apache para medir el rendimiento de los servidores web HTTP. Esto le muestra especialmente cuántas solicitudes por segundo su Apache es capaz de atender al generar una avalancha de solicitudes a una URL determinada y devuelve a la pantalla algunas métricas relacionadas con el rendimiento fácilmente digeribles.

Por ejemplo, el siguiente comando ejecutará 1000 solicitudes HTTP GET, procesando hasta 10 solicitudes al mismo tiempo, a la URL especificada.

ab -k -n 1000 -c 10 "http://elhacker.net/ddos"

modsecurity en Apache 2.4

 

 

 modSecurity filtra ataques por XSS, SQL Injection, comportamientos anómalos en protocolos, robots, troyanos, LFI ... incorporando además reglas específicas para algunos de los gestores de contenido más populares como Joomla o Wordpress. modSecurity también funciona con nginx e IIS.

modSecurity es un firewall de aplicaciones Web embebible bajo licencia GNU  que se ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente.

ModSecurity cuenta con una consola de administración que permite recopilar registros de monitorización y alertas en tiempo real así como de opciones automatizadas de mantenimiento, entre otras características.


yum install mod_security mod_security_crs

edit the /etc/httpd/conf.d/mod_security.conf

SecRuleEngine option. You can choose between On, Off and Detection Only.

  • On: The rules are enforced and connections will be terminated when matching rules are found.
  • Detect Only: The rules are enforced and connections will be logged when matching rules are found. Not traffic will be dropped.
  • Off: Rules are not enforced.

Mod Security Config File – /etc/httpd/conf.d/mod_security.conf
Debug Log – /var/log/httpd/modsec_debug.log
Audit log – /var/log/httpd/modsec_audit.log
Rules – /etc/httpd/modsecurity.d/activated_rules

#SecRuleEngine DetectionOnly
SecRuleEngine On
SecAuditLog /var/log/apache2/modsec_audit.log


Para entender los registros de auditoría de ModSecurity, necesita conocer las 5 fases de procesamiento en ModSecurity, que son:

  • Phase 1: Inspeccionar las cabeceras de la petición
  • Phase 2: Inspeccionar el cuerpo de la petición
  • Phase 3: Inspeccionar las cabeceras de la respuesta
  • Phase 4: Inspeccionar el cuerpo de la respuesta
  • Phase 5: Acción (registrar/bloquear peticiones maliciosas)

También hay dos tipos de archivos de registro.

  • Serial: un archivo para todos los registros. Este es el predeterminado.
  • Concurrent: varios archivos de registro. Esto puede proporcionar un mejor rendimiento de escritura. Si nota que sus páginas web se ralentizan después de activar ModSecurity, puede elegir usar el tipo de registro concurrente.

Los eventos en el registro se dividen en varias secciones (sections)

sección A: cabecera del registro de auditoría
sección B: cabecera de la petición
sección C: cuerpo de la petición
sección D: reservado
sección E: cuerpo de la respuesta intermedia
sección F: cabecera de la respuesta final
sección G: reservada
sección H: tráiler del registro de auditoría
sección I: alternativa al cuerpo compacto de la solicitud, que excluye los archivos
sección J: información sobre los archivos cargados
sección K: todas las reglas coincidentes con un evento, por orden de coincidencia
sección Z: límite final


Si tiene un sitio web con mucho tráfico, el log de auditoría de ModSecurity puede volverse demasiado grande muy rápidamente, por lo que necesitamos configurar la rotación de logs para el log de auditoría de ModSecurity. Cree un fichero de configuración logrotate para ModSecurity.


sudo nano /etc/logrotate.d/modsecurity

Añada las siguientes líneas a este fichero.

/var/log/httpd/modsec_audit.log
{
        rotate 10
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Esto rotará el archivo de registro cada día (daily), comprimiendo las versiones antiguas (compress). Los 10 archivos de registro anteriores se mantendrán (rotate 10), y no se producirá ninguna rotación si el archivo está vacío (notifempty). 


Excluir reglas por ID (identificador)
SecRuleRemoveById 920350


Excluir rango de reglas:

 SecRuleRemoveById "9000-9010"

Excluir reglas según tipo:

SecRuleRemoveByTag "WEB_ATTACK/XSS"  

OWASP ModSecurity CRS incluye:

  • AUTOMATION/MALICIOUS
  • AUTOMATION/MISC
  • AUTOMATION/SECURITY_SCANNER
  • LEAKAGE/SOURCE_CODE_ASP_JSP
  • LEAKAGE/SOURCE_CODE_CF
  • LEAKAGE/SOURCE_CODE_PHP
  • WEB_ATTACK/CF_INJECTION
  • WEB_ATTACK/COMMAND_INJECTION
  • WEB_ATTACK/FILE_INJECTION
  • WEB_ATTACK/HTTP_RESPONSE_SPLITTING
  • WEB_ATTACK/LDAP_INJECTION
  • WEB_ATTACK/PHP_INJECTION
  • WEB_ATTACK/REQUEST_SMUGGLING
  • WEB_ATTACK/SESSION_FIXATION
  • WEB_ATTACK/SQL_INJECTION
  • WEB_ATTACK/SSI_INJECTION
  • WEB_ATTACK/XSS 

 

Excluir reglas según directorio:
<LocationMatch "/wp-admin/post.php">
    SecRuleRemoveById 980130 941180 949110
</LocationMatch>


Excluir reglas según IP (WhiteList) (cambia IP por tu dirección IP)
SecRule REMOTE_ADDR "@IPMatch IP" "id:932160,ctl:ruleEngine=Off"
SecRule REMOTE_ADDR "@IPMatch IP" "id:980130,ctl:ruleEngine=Off"

SecRule REMOTE_ADDR "@ipMatch IP" "id:980130,phase:2,t:none,log,allow"
SecRule REMOTE_ADDR "@ipMatch IP" "id:941180,phase:2,t:none,log,allow"

Para la IP 127.0.0.1

SecRule REMOTE_ADDR "^127\.0\.0\.1" "id:1004,phase:1,allow,ctl:ruleEngine=off"

Para una subred 10.10.10.0/24
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"




Ejemplo configuración básico:
<IfModule mod_security2.c>
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream
SecDataDir /tmp
</IfModule>


Reglas OWASP ModSecurity Core Rule Set (CRS)



 

Las reglas han sido movidas:



# mkdir /etc/httpd/crs-tecmint
# cd /etc/httpd/crs-tecmint
# wget -c https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0.tar.gz -O master
# tar xzf master
# mv owasp-modsecurity-crs-3.2.0 owasp-modsecurity-crs
# cd owasp-modsecurity-crs/
# cp crs-setup.conf.example crs-setup.conf

<IfModule security2_module>
Include crs-tecmint/owasp-modsecurity- Include crs-tecmint/owasp-modsecurity-crs/rules/*.conf
</IfModule>


Falsos Positivos 

Editar el fichero

crs-setup.conf

Ves a la sección Exclusiones de reglas específicas de la aplicación y busca las siguientes líneas.

 

#SecAction \
# "id:900130,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.crs_exclusions_cpanel=1,\
# setvar:tx.crs_exclusions_drupal=1,\
# setvar:tx.crs_exclusions_dokuwiki=1,\
# setvar:tx.crs_exclusions_nextcloud=1,\
# setvar:tx.crs_exclusions_wordpress=1,\
# setvar:tx.crs_exclusions_xenforo=1"


Por ejemplo, si quiero activar las exclusiones de WordPress, las líneas anteriores deben cambiarse por las siguientes:


SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_wordpress=1"


Exclusiones para un subdominio:

SecRule REQUEST_HEADERS:Host "@streq blog.elhacker.net" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"

Por ejemplo un subdominio con nextcloud:

SecRule REQUEST_HEADERS:Host "@streq nextcloud.elhacker.net" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"

 modsecurity + Fail2ban

modsecurity se puede integrar fácilmente con Fail2Ban


[apache-modsecurity]
enabled = true
filter = apache-modsecurity
#logpath  = /var/log/httpd/modsec_audit.log
backend = pyinotify
action = abuseipdb[abuseipdb_category="15,21"]
bantime = 1h
logencoding = UTF-8


Proxy Inverso con Apache (Reverse proxy)

Un proxy inverso es un tipo de servidor proxy que recupera recursos en nombre de un cliente desde uno o más servidores. Por lo tanto el cliente hace la petición al puerto 80 del proxy, y éste es el que hace la petición al servidor web que normalmente está en una red interna no accesible desde el cliente.

Esta funcionalidad la podemos usar por ejemplo para acceder al contenido de un contenedor docker local funcionando en otro puerto.


  • ServerName: la directiva ServerName define bajo qué nombres primarios se puede acceder a un servidor en Internet. Estos tienen que poder resolverse o bien vía DNS o por medio de los /etc/hosts. En el ejemplo se le indica al servidor Apache que tiene que hacerse cargo de todas las solicitudes en domain.tld.
  • ProxyPass: la directiva ProxyPass define la dirección de destino para los reenvíos. El servidor proxy inverso reenviará todas las peticiones dirigidas a la dirección depositada bajo la etiqueta ServerName a la dirección interna consignada en el argumento de la directiva ProxyPass. En el ejemplo se trataría de la dirección IP ficticia 123.456.7.89.
  • ProxyPassReverse: un proxy server no solo se ocupa de las peticiones, sino que también transmite los paquetes de respuesta del servidor backend a los clientes. Para impedir que dichas respuestas se entreguen con datos de encabezado que no sean correctos (es decir, con datos del servidor en un segundo plano), la directiva ProxyPassReverse transcribe el encabezamiento de las respuestas del servidor de tal manera que estas se adapten al servidor proxy. El servidor backend permanece anónimo.  

Además, en el ejemplo aparecen dos directivas adicionales: ServerAlias y ProxyRequests. Estas no ofrecen funciones básicas para el servidor proxy y son, por lo tanto, facultativas.

  • ServerAlias: la directiva ServerAlias permite, junto al nombre del servidor primario, definir un nombre alternativo para el servidor de destino.
  • ProxyRequest: la directiva ProxyRequests con el argumento Off impide que se utilice el servidor Apache HTTP como proxy forward o de reenvío para evitar posibles abusos. 

Apache2.4 puede funcionar como proxy inverso usando el módulo proxy junto a otros módulos, por ejemplo:

  • proxy_http: Para trabajar con el protocolo HTTP.
  • proxy_ftp: Para trabajar con el protocolo FTP.
  • proxy_html: Permite reescribir los enlaces HTML en el espacio de direcciones de un proxy.
  • proxy_ajp: Para trabajar con el protocolo AJP para Tomcat.
Añadir configuración ProxyPass y ProxyPassReverse sitio externo, sitio interno:

Dentro del vhost añadir directivas o Location (carpeta)
ProxyPass  "/" "http://192.168.0.5:8080/"

Ahora bien, la directiva ProxyPassReverse sólo modifica las cabeceras anteriormente citadas. Si en la página www.interno.com existen enlaces absolutos, éstos no son modificados. 

Para que funcionen todas las rutas:

ProxyHTMLURLMap /

Para que funcionen enlaces:

ProxyHTMLEnable On

y ficheros JS y ficheros CSS:

ProxyHTMLExtended On

Vamos a explicar cómo excluir un determinado subdirectorio o ruta cuando ya hemos configurado un proxy inverso en Apache (módulo mod_proxy) que por defecto incluye esa URL. Un ejemplo para verlo más claro:

[...]
ServerName           foo.com
[...]
ProxyPass            /    http://localhost:4789
ProxyPassReverse     /    http://localhost:4789
[...]

La configuración especificada en el ejemplo anterior iría normalmente dentro de un virtualhost de Apache, ya sea en httpd.conf o en otro fichero de configuración mediante include. Básicamente, indica que toda petición que vaya dirigida al raíz (/) de foo.com será redirigida a http://localhost:4789.

¿Qué sucede si quiero que esto sea así a excepción de para la URL http://foo.com/bar? En ese caso, hay que excluir de forma explícita ese path para que no sea redirigido a través del proxy inverso del siguiente modo:

[...]
ServerName           foo.com
[...]
ProxyPass            /bar/ !
ProxyPass            /    http://localhost:4789
ProxyPassReverse     /    http://localhost:4789
[...] 

Al especificar la ruta seguida de ! se indica explícitamente que esa URL no será manejada por las directivas de proxy inverso. 


Autenticación Digest y Basic

Podemos proteger un directorio o página mediante contraseña;

<Location /direcotrio>
    AuthUserFile /home/alex/htpasswd
    AuthType Basic
    AuthName "Directorio protegdio"
    require valid-user
</Location>

Para crear los usuarios

htpasswd -nB alex

Y pega el resultado en: /home/alex/htpasswd


Recuerda usar siempre https en autenticación Basic

Podemos hacer que pida contraseña o bien si es una ip de confianza no la pida:

<Location /directorio>

    AuthUserFile /home/alex/htpasswd

    AuthType Basic

    AuthName "Directorio protegido menos para la IP x"

    require valid-user

    Order deny,allow

    Deny from all

    Allow from IP x

    Allow from ns2.elhacker.net

# o password o ip correcta

   Satisfy any

</Location>

O si queremos que pida contraseña ya demás la ip sea correcta cambiar el any por all en el Satisfy

Satisfy ALL

Apache suExec


La función suEXEC proporciona a los usuarios del servidor HTTP Apache la capacidad de ejecutar programas CGI y SSI con ID de usuario diferentes de la ID de usuario del servidor web que realiza la llamada. Normalmente, cuando se ejecuta un programa CGI o SSI, se ejecuta como el mismo usuario que ejecuta el servidor web.

Si se utiliza correctamente, esta función puede reducir considerablemente los riesgos de seguridad relacionados con permitir que los usuarios desarrollen y ejecuten programas CGI o SSI privados. Sin embargo, si suEXEC está configurado incorrectamente, puede causar una serie de problemas y posiblemente crear nuevos agujeros en la seguridad de su computadora. Si no está familiarizado con la administración de los programas raíz de setuid y los problemas de seguridad que presentan, le recomendamos que no considere usar suEXEC.

Errores comunes:

Documentación Oficial
En el vhost de Apache:

    SuexecUserGroup "#1001" "#1001"

Añadimos el ID del usuario en cuestión.

suexec requiere que el CGI esté dentro del  DocumentRoot (no e VirtualHost DocumentRoot) del servidor Apache.  Sin embargo, está permitido que VirtualHost DocumentRoot sea un enlace simbólico a un directorio que aparece debajo del DocumentRoot real.
 
Error que aparece que el script no está en  el docroot
command not in docroot 

Por ejemplo por defecto el suexec compilado de Centos está en /var/www  y no podemos ejecutar scripts en /home por ejemplo /home/usuario/cgi-bin/script.cgi

[root@ns2 rpmbuild]# /usr/sbin/suexec -V
 -D AP_DOC_ROOT="/var/www"
 -D AP_GID_MIN=1000
 -D AP_HTTPD_USER="apache"
 -D AP_LOG_SYSLOG
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=1000
 -D AP_USERDIR_SUFFIX="public_html"
En  Ubuntu y otras distribuciones existe un 

apache2-suexec-custom

Que permite cambiar el path (ruta) sin tener que recompilar. Pero en CentOS no es posible. 

En CentOS deberemos bajar el SRC para poderlo recompilar desde las fuentes
 
rpm -Uvh httpd-2.4.37.xxx.centos.src.rpm
Esto creará en el direcotrio root una carpeta scon el nombre de rpmbuild:

/root/rpmbuild/SOURCES/httpd-2.4.37.tar.gz
Descomprimirlo:

# cd /root/rpmbuild/SOURCES/
# tar xvzf httpd-2.4.37.tar.gz


Y ahora toca recompilar con el nuevo path (ruta)

cd /root/rpmbuild/httpd-2.4.37
 Nuevas opciones  docroot=/home

./configure --enable-suexec --with-suexec-docroot=/hone --with-suexec-caller=apache --without-suexec-logfile --with-suexec-syslog
make -j4
Podemos ver las opciones utilizadas en el configure en

/root/rpmbuild/SOURCES/httpd-2.4.37/config.log

Esto nos genera un nuevo binario suexec en la carpeta:

/root/rpmbuild/SOURCES/httpd-2.4.37/support/suexec
 Ahora solo falta instalarlo donde toca:

Primero hacemos una copia de seguridad del original

 cp -a /usr/sbin/suexec{,.bak}
 
copiamos el nuevo

 cp /root/rpmbuild/SOURCES/httpd-2.4.37/support/suexec /usr/sbin/suexec
Y aplicamos permisos:


# chown root:root /usr/sbin/suexec
# chmod 4755 /usr/sbin/suexec
Por último reiniciamos apache (httpd) service httpd restart o systemctl reload httpd.service
 
Podemos ver las opciones por defecto anteriormente:
 
/root/rpmbuild/SPECS/httpd.spec
--enable-suexec --with-suexec \
--enable-suexec-capabilities \
--with-suexec-caller=%{suexec_caller} \
--with-suexec-docroot=/home \
--without-suexec-logfile \
--with-suexec-syslog \
--with-suexec-bin=%{_sbindir}/suexec \
--with-suexec-uidmin=1000 --with-suexec-gidmin=1000 \

Migrar Apache 2.2 a Apache 2.4

Uno de los cambios más importantes que de momento se mantiene por compatibilidad son las directivas Order deny,allow

Allow from all
ahora es:
Require all granted

Deny from all
ahora es:
Require all denied

Ejemplo:

<IfModule mod_authz_core.c>
# Apache 2.4
Require all denied
Require ip 127.0.0.1
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order deny,allow
Deny from all
Allow from 127.0.0.1
</IfModule>


https://httpd.apache.org/docs/2.4/upgrading.html 


Etiquetas: , , , , , , , , , , ,

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.