Por SSH:
Si queremos limitar la cantidad de accesos simultáneos vía FTP desde una misma IP debemos editar el archivo pure-ftp.conf y buscar:
# Maximum number of sim clients with the same IP address
MaxClientsPerIP 8
Colocar 1 al final como se muestra, reiniciar el servicio FTP y listo.
Por WHM:
WHM > FTP Server Configuration > Maximum Connections Per IP Address > 8 > Save
Generalidades:
ModSecurity es un firewall de aplicaciones Web embebible que se ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorear tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente. El módulo cuenta con diversas funcionalidades como son:
Para instalar mod_security de la forma más sencilla en CentOS debemos habilitar previamente el repositorio EPEL (Extra Packages for Enterprise Linux) ejecutando:
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
Para verificarlo podemos listar los repositorios existentes con:
yum repolist
Esto puede tomar algunos minutos debido a que debe actualizarse la lista de contenidos de c/u de los repositorios. Una vez ejecutado mostrará:
repo id repo name status
addons CentOS-5 – Addons enabled : 0
base CentOS-5 – Base enabled : 2535
epel Extra Packages for Enterprise Linux 5 – enabled : 4066
extras CentOS-5 – Extras enabled : 327
updates CentOS-5 – Updates enabled : 620
Luego, para instalar un paquete los comandos serían:
yum search nombre-paquete
yum install nombre-paquete
Ahora, para instalar mod_security debemos ejecutar:
yum install mod_security
Esto tomará pocos minutos y debemos responder “y” a lo que nos pregunte. Adicionalmente instalará “Lua” para el correcto funcionamiento de mod_security.
En los servidores de desarrollo los archivos de configuración están ubicados en:
Archivo principal de configuración de mod_security:
/etc/httpd/conf.d/mod_security.conf
Resto de archivos de configuración para mod_security:
Configuración especial a adecuar para los requermientos específicos antes de su uso:
Uso de mensajes de depuración para las reglas y problemas asociados a mod_security:
Todas las solicitudes que disparan eventos de mod_security o errores son registrados en:
Para poder proteger al servidor de los ataques web debemos editar:
nano /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
Buscamos el parámetro SecRuleEngine y lo colocamos en “On”:
SecRuleEngine On
Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:
/usr/sbin/httpd -t
Si todo está bien mostrará “Syntax OK”.
Ahora debemos re-arrancar al apache:
service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)
Para verificar que todo esta OK podemos ejecutar:
tail -f /var/log/httpd/error_log (ó según la ubicación del archivo puede ser tail -f /usr/local/apache/logs/error_log)
Esto debe mostrar algo como:
[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
Ahora para verificar además que el PHP es capaz de procesar el mod_security debe tener incluído este módulo. Para verificarlo debemos crear el archivo phpinfo.php en un directorio web con el siguiente contenido:
<?php phpinfo();?>
Luego ejecutar el archivo vía web y deberá mostrar el listado de módulos y configuración del PHP. Buscamos mod_security y debería conseguirse en pantalla mod_security2 indicando así que efectivamente podrá procesarlo.
Para probar si el mod_security esta haciendo su labor, debemos ejecutar cualquier archivo web y colocar alguna palabra (comado) prohibido, por ejemplo:
http://phpinfo.desh/index.html?name=wget
Esto debería generar un Error 403 (No tiene permiso para acceder al URL requerido).
Manejo de mod_security en los Servidores de Producción basados en cPanel/WHM
Para activar el Mod_security en los servidores de producción solo debemos hacer lo siguiente:
WHM > Plugins > Mod Security > Edit Config > Default Configuration > Save Configuration
Y ya quedará funcionando con las reglas estándar de WHM/cPanel.
Adicionalmente, es importante conocer lo siguiente:
En los servidores de producción los archivos de configuración están ubicados en:
Archivo principal de configuración de mod_security:
Resto de archivos de configuración para mod_security:
Uso de mensajes de depuración para las reglas y problemas asociados a mod_security:
Todas las solicitudes que disparan eventos de mod_security o errores son registrados en:
Para poder proteger al servidor de los ataques web debemos editar:
Buscamos el parámetro SecRuleEngine y lo colocamos en “On”:
SecRuleEngine On
Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:
/usr/sbin/httpd -t
Si todo está bien mostrará “Syntax OK”.
Ahora debemos re-arrancar al apache:
service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)
Para verificar que todo esta OK podemos ejecutar:
tail -f /usr/local/apache/logs/error_log
Esto debe mostrar algo como:
[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
Ahora para verificar además que el PHP es capaz de procesar el mod_security debe tener incluído este módulo. Para verificarlo debemos crear el archivo phpinfo.php en un directorio web con el siguiente contenido:
<?php phpinfo();?>
Luego ejecutar el archivo vía web y deberá mostrar el listado de módulos y configuración del PHP. Buscamos mod_security y debería conseguirse en pantalla mod_security2 indicando así que efectivamente podrá procesarlo.
Para probar si el mod_security esta haciendo su labor, debemos ejecutar cualquier archivo web y colocar alguna palabra (comado) prohibido, por ejemplo:
http://dominio.com/index.html?name=wget
Esto debería generar un Error 403 (No tiene permiso para acceder al URL requerido).
IMPORTANTE: Las reglas de mod_security 1.X son únicamente para Apache 1.X mientras que las reglas de mod_security 2.x con para el Apache 2.x. No existe compatibilidad entre la sintaxis de las reglas 1.X y las reglas 2.X. Para este curso sólo explicamos lo referente a Apache 2.x debido a que la versión 1.x se considera obsoleta. Debemos estar pendientes de utilizar las reglas correctas porque si se usan las incorrectas el Apache podría fallar. En cualquier cambio que se haga al archivo de configuración de reglas deberá crearse un respaldo previamente para luego retornarlo en el caso de falla.
Para saber si php ha sido compilado con mod_security debemos ejecutar desde php la función phpinfo() y buscar mod_security (para apache 1.x) ó mod_security2 (para apache 2.x).
Reglas Básicas para Apache 2.X (mod_security2) para Servidores de Producción:
Para aplicar estas reglas en Apache 2.X donde se ha compilado el mod-security2 debemos:
Verificar la existencia de /usr/local/apache/conf/modsec2.conf
Si no existe debemos entrar por WHM y recompilar el Apache y PHP marcando la opción mod_security para que lo inicialice. Luego continuamos con la instalación de las reglas de seguridad propias.
Editar:
nano /usr/local/apache/conf/modsec2.conf
Verificar que su contenido sea:
LoadFile /opt/xml2/lib/libxml2.so
LoadFile /opt/lua/lib/liblua.so
LoadModule security2_module modules/mod_security2.so
<IfModule mod_security2.c>
SecRuleEngine On
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf
# "Add the rules that will do exactly the same as the directives"
# SecFilterCheckURLEncoding On
# SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_audit.log
SecDebugLog logs/modsec_debug_log
SecDebugLogLevel 0
SecDefaultAction "phase:2,deny,log,status:406"
SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow
Include "/usr/local/apache/conf/modsec2.user.conf"
</IfModule>
Editar nano modsec2.user.conf:
nano /usr/local/apache/conf/modsec2.user.conf
Colocar en el archivo:
# Deprectaed due to security issues so it shoudl be off: http://blog.modsecurity.org/2008/08/transformation.html
SecCacheTransformations Off
# Check Content-Length and reject all non numeric ones
SecRule REQUEST_HEADERS:Content-Length "!^\d+$" "deny,log,auditlog,msg:'Content-Length HTTP header is not numeric', severity:'2',id:'960016'"
# Do not accept GET or HEAD requests with bodies
SecRule REQUEST_METHOD "^(GET|HEAD)$" "chain,deny,log,auditlog,msg:'GET or HEAD requests with bodies', severity:'2',id:'960011'"
SecRule REQUEST_HEADERS:Content-Length "!^0?$"
# Require Content-Length to be provided with every POST request.
SecRule REQUEST_METHOD "^POST$" "chain,deny,log,auditlog,msg:'POST request must have a Content-Length header',id:'960012',severity:'4'"
SecRule &REQUEST_HEADERS:Content-Length "@eq 0"
# Don't accept transfer encodings we know we don't know how to handle
SecRule HTTP_Transfer-Encoding "!^$" "deny,log,auditlog,msg:'ModSecurity does not support transfer encodings',id:'960013',severity:'5'"
# Check decodings
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "@validateUrlEncoding" \
"chain, deny,log,auditlog,msg:'URL Encoding Abuse Attack Attempt',id:'950107',severity:'4'"
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})"
NOTA: La regla 950801 debe eliminarse porque causa problemas con los acentos y las ñ.
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "@validateUtf8Encoding" "deny,log,auditlog,msg:'UTF8 Encoding Abuse Attack Attempt',id:'950801',severity:'4'"
# Proxy access attempt
SecRule REQUEST_URI ^http:/ "deny,log,auditlog,msg:'Proxy access attempt', severity:'2',id:'960014'"
#
# Restrict type of characters sent
SecRule REQUEST_FILENAME|REQUEST_HEADERS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer \
"@validateByteRange 1-255" \
"log,auditlog,msg:'Request Missing an Accept Header', severity:'2',id:'960015',t:urlDecodeUni,phase:1"
SecRule ARGS|ARGS_NAMES "@validateByteRange 1-255" \
"deny,log,auditlog,msg:'Invalid character in request',id:'960901',severity:'4',t:urlDecodeUni,phase:2"
# allow request methods
SecRule REQUEST_METHOD "!^((?:(?:POS|GE)T|OPTIONS|HEAD))$" \
"phase:1,log,auditlog,msg:'Method is not allowed by policy', severity:'2',id:'960032'"
# Restrict file extension
# removed exe so that frontpage will work
# Restricted HTTP headers
SecRule REQUEST_HEADERS_NAMES "\.(?:Lock-Token|Translate|If)$" \
"deny,log,auditlog,msg:'HTTP header is restricted by policy',id:'960038',severity:'4'"
SecRule HTTP_User-Agent "(?:\b(?:m(?:ozilla\/4\.0 compatible
|etis)|webtrends security analyzer|pmafind)\b|n(?:-stealth|sauditor|essus|ikto)|b(?:lack ?widow|rutus|ilbo)|(?:jaascoi|paro)s|internet explorer|webinspect|\.nasl)" \
"deny,log,auditlog,msg:'Request Indicates a Security Scanner Scanned the Site',id:'990002',severity:'2'"
SecRule REQUEST_HEADERS_NAMES "\bacunetix-product\b" \
"deny,log,auditlog,msg:'Request Indicates a Security Scanner Scanned the Site',id:'990901',severity:'2'"
SecRule REQUEST_FILENAME "^/nessustest" \
"deny,log,auditlog,msg:'Request Indicates a Security Scanner Scanned the Site',id:'990902',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "(?:m(?:ozilla\/(?:4\.0 \(compatible; advanced email extractor|2\.0 compatible;newtactivex;win32
)|ailto:craftbot\@yahoo\.com)|e(?:mail(?:(?:collec|harves|magne)t|(?: extracto|reape)r|siphon|wolf)|(?:collecto|irgrabbe)r|xtractorpro|o browse)|a(?:t(?:tache|hens)|utoemailspider|dsarobot)|w(?:eb(?:emailextrac| by mail)|3mir)|f(?:astlwspider|loodgate)|p(?:cbrowser|ackrat|surf)|(?:digout4uagen|takeou)t|(?:chinacla|be)w|hhjhj@yahoo|rsync|shai|zeus)" \
"deny,log,auditlog,msg:'Rogue web site crawler',id:'990012',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "(?:\b(?:(?:indy librar|snoop)y|microsoft url control|lynx)\b|d(?:ownload demon|isco)|w(?:3mirror|get)|l(?:ibwww|wp)|p(?:avuk|erl)|cu(?:sto|rl)|big brother|autohttp|netants|eCatch)" \
"chain,log,auditlog,msg:'Request Indicates an automated program explored the site',id:'990011',severity:'5'"
SecRule REQUEST_HEADERS:User-Agent "!^apache.*perl"
# Session fixation
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\.cookie\b.*?;\W*?(?:expires|domain)\W*?=|\bhttp-equiv\W+set-cookie\b)" \
"capture,ctl:auditLogParts=+E,log,auditlog,msg:'Session Fixation. Matched signature <%{TX.0}>',id:'950009',severity:'2'"
# Blind SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:ys\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)s|c(?:onstraints|atalog))|all_tables|tab)|elect\b.{0,40}\b(?:substring|ascii|user))|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql.user)|c(?:onstraint_type|harindex)|attnotnull)\b|(?:locate|instr)\W+\()|\@\@spid\b)" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950007',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|(?:dba|mb)_users|xtype\W+\bchar|rownum)\b|t(?:able_name\b|extpos\W+\())" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950904',severity:'2'"
# SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:elect\b(?:.{1,100}?\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|variant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresultset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomous_transaction|open(?:rowset|query)|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+?(?:\d{1,10}|'[^=]{1,10}')\s*?[=<>]+|(?:print\]\b\W*?\@|root)\@|c(?:ast\b\W*?\(|oalesce\b))|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|msdasql|dbo)')" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950001',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:user_(?:(?:object|table|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|substr(?:ing)?|table_name|mb_users|rownum)\b" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950906',severity:'2'"
# XSS
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:\b(?:on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|ivescript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|background-image|mocha):|type\b\W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b| [vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=.*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|shell|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[|script|meta)|(?:\.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|innerhtml)|\@import)\b)" \
"capture,ctl:auditLogParts=+E,log,auditlog,msg:'Cross-site Scripting (XSS) Attack. Matched signature <%{TX.0}>',id:'950004',severity:'2'"
# file injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:\b(?:\.(?:ht(?:access|passwd|group)|www_?acl)|global\.asa|httpd\.conf|boot\.ini)\b|\/etc\/)" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'Remote File Access Attempt. Matched signature <%{TX.0}>',id:'950005',severity:'2'"
# Command access
SecRule REQUEST_FILENAME "\b(?:n(?:map|et|c)|w(?:guest|sh)|cmd(?:32)?|telnet|rcmd|ftp)\.exe\b" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'System Command Access. Matched signature <%{TX.0}>',id:'950002',severity:'2'"
# Command injection
SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:\b(?:(?:n(?:et(?:\b\W+?\blocalgroup|\.exe)|(?:map|c)\.exe)|t(?:racer(?:oute|t)|elnet\.exe|clsh8?|ftp)|(?:w(?:guest|sh)|rcmd|ftp)\.exe|echo\b\W*?\by+)\b|c(?:md(?:(?:32)?\.exe\b|\b\W*?\/c)|d(?:\b\W*?[\\\/]|\W*?\.\.)|hmod.{0,40}?\+.{0,3}x))|[\;\|\`]\W*?\b(?:(?:c(?:h(?:grp|mod|own|sh)|md|pp|c)|p(?:asswd|ython|erl|ing|s)|n(?:asm|map|c)|f(?:inger|tp)|(?:kil|mai)l|(?:xte)?rm|ls(?:of)?|telnet|uname|echo|id)\b|g(?:\+\+|cc\b))|\/(?:c(?:h(?:grp|mod|own|sh)|pp|c)|p(?:asswd|ython|erl|ing|s)|n(?:asm|map|c)|f(?:inger|tp)|(?:kil|mai)l|g(?:\+\+|cc)|(?:xte)?rm|ls(?:of)?|telnet|uname|echo|id)(?:[\'\"\|\;\`\-\s]|$))" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'System Command Injection. Matched signature <%{TX.0}>',id:'950006',severity:'2'"
SecRule "ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:User-Agent" \
"\bwget\b" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'System Command Injection. Matched signature <%{TX.0}>',id:'950907',severity:'2'"
# SSI injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "<!--\W*?#\W*?(?:e(?:cho|xec)|printenv|include|cmd)" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'SSI injection Attack. Matched signature <%{TX.0}>',id:'950011',severity:'2'"
# PHP injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:(?:\b(?:f(?:tp_(?:nb_)?f?(?:ge|pu)t|get(?:s?s|c)|scanf|write|open|read)|gz(?:(?:encod|writ)e|compress|open|read)|s(?:ession_start|candir)|read(?:(?:gz)?file|dir)|move_uploaded_file|(?:proc_|bz)open)|\$_(?:(?:pos|ge)t|session))\b|<\?(?!xml))" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'PHP Injection Attack. Matched signature <%{TX.0}>',id:'950013',severity:'2'"
Salir y Guardar.
Para aplicar estas reglas en Apache 2.X en los servidores de desarrollo debemos cumplir con el siguiente procedimiento:
Cargar el Kit de Reglas Avanzadas de mod_security2 de TecnoSoluciones (reglas-mod_security2.zip) en el directorio del usuario que se conecta por SFTP (ej. /home/tecno).
Descomprimir el archivo con: unzip reglas-mod_security2.zip
Esto creará dos directorios: /home/tecno/base_rules y /home/tecno/more_rules
Cambiarse al directorio de reglas del mod_security y crear ambos directorios, para pasar luego los archivos creados para los mismos con:
cd /etc/httpd/modsecurity.d/
mkdir /etc/httpd/modsecurity.d/base_rules
mkdir /etc/httpd/modsecurity.d/more_rules
cp /home/tecno/base_rules/* /etc/httpd/modsecurity.d/base_rules/
cp /home/tecno/more_rules/* /etc/httpd/modsecurity.d/more_rules/
Editar el archivo de configuración de mod_security y agregar los include de los archivos de las reglas con:
nano /etc/httpd/conf.d/mod_security.conf
Ubicar el bloque que dice <IfModule mod_security2.c> “¦. </IfModule> y colocar justo al final antes del cierre del bloque </IfModule> lo siguiente:
#Reglas adicionales de TecnoSoluciones (Incluye reglas de GotRoot)
Include modsecurity.d/base_rules/modsecurity_crs_20_protocol_violations.conf
Include modsecurity.d/base_rules/modsecurity_crs_21_protocol_anomalies.conf
Include modsecurity.d/base_rules/modsecurity_crs_23_request_limits.conf
Include modsecurity.d/base_rules/modsecurity_crs_30_http_policy.conf
Include modsecurity.d/base_rules/modsecurity_crs_35_bad_robots.conf
Include modsecurity.d/base_rules/modsecurity_crs_40_generic_attacks.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_phpids_converter.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_phpids_filters.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_xss_attacks.conf
Include modsecurity.d/base_rules/modsecurity_crs_42_tight_security.conf
Include modsecurity.d/base_rules/modsecurity_crs_45_trojans.conf
Include modsecurity.d/base_rules/modsecurity_crs_47_common_exceptions.conf
Include modsecurity.d/base_rules/modsecurity_crs_48_local_exceptions.conf
Include modsecurity.d/base_rules/modsecurity_crs_49_enforcement.conf
Include modsecurity.d/base_rules/modsecurity_crs_49_inbound_blocking.conf
Include modsecurity.d/base_rules/modsecurity_crs_50_outbound.conf
Include modsecurity.d/base_rules/modsecurity_crs_59_outbound_blocking.conf
Include modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf
Include modsecurity.d/base_rules/modsecurity_localrules.conf
#Include modsecurity.d/more_rules/00_asl_rbl.conf
#Include modsecurity.d/more_rules/00_asl_whitelist.conf
Include modsecurity.d/more_rules/05_asl_exclude.conf
Include modsecurity.d/more_rules/05_asl_scanner.conf
Include modsecurity.d/more_rules/10_asl_antimalware.conf
Include modsecurity.d/more_rules/10_asl_rules.conf
Include modsecurity.d/more_rules/11_asl_data_loss.conf
Include modsecurity.d/more_rules/20_asl_useragents.conf
Include modsecurity.d/more_rules/30_asl_antimalware.conf
Include modsecurity.d/more_rules/30_asl_antispam.conf
Include modsecurity.d/more_rules/30_asl_antispam_referrer.conf
Include modsecurity.d/more_rules/40_asl_apache2-rules.conf
Include modsecurity.d/more_rules/50_asl_rootkits.conf
Include modsecurity.d/more_rules/60_asl_recons.conf
Include modsecurity.d/more_rules/99_asl_exclude.conf
Include modsecurity.d/more_rules/99_asl_jitp.conf
Include modsecurity.d/more_rules/trusted-domains.conf
Salir y Guardar el archivo
Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:
/usr/sbin/httpd -t
Si todo está bien mostrará “Syntax OK”.
Ahora debemos re-arrancar al apache:
service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)
Para verificar que todo esta OK podemos ejecutar:
tail -f /var/log/httpd/error_log
Esto debe mostrar algo como:
[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
Reglas Avanzadas para Apache 2.X (mod_security2) para Servidores de Producción:
NOTA: Estas reglas aún no han sido depuradas para ser colocadas en nuestros servidores de producción por lo que deben revisarse primero para no crear fallas.
Para aplicar estas reglas en Apache 2.X en los servidores de Producción basados en cPanel/WHM debemos cumplir con el siguiente procedimiento:
Cargar el Kit de Reglas Avanzadas de mod_security2 de TecnoSoluciones (reglas-mod_security2.zip) en el directorio del usuario que se conecta por SFTP (ej. /home/adminX1).
Descomprimir el archivo con: unzip reglas-mod_security2.zip
Esto creará dos directorios: /home/adminx1/base_rules y /home/ adminx1/more_rules
Cambiarse al directorio de reglas del mod_security y crear ambos directorios, para pasar luego los archivos creados para los mismos con:
cd /usr/local/apache/conf/
mkdir /usr/local/apache/conf/base_rules
mkdir /usr/local/apache/conf/more_rules
cp /home/adminx1/base_rules/* /usr/local/apache/conf/base_rules
cp /home/adminx1/more_rules/* /usr/local/apache/conf/more_rules
Editar el archivo de configuración de mod_security para el usuario y agregar los include de los archivos de las reglas con:
/usr/local/apache/conf/modsec2.user.conf
Colocar lo siguiente:
#Reglas adicionales de TecnoSoluciones (Incluye reglas de GotRoot)
Include /usr/local/apache/conf/base_rules/modsecurity_crs_20_protocol_violations.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_21_protocol_anomalies.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_23_request_limits.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_30_http_policy.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_35_bad_robots.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_40_generic_attacks.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_phpids_converter.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_phpids_filters.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_xss_attacks.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_42_tight_security.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_45_trojans.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_47_common_exceptions.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_48_local_exceptions.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_49_enforcement.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_49_inbound_blocking.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_50_outbound.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_59_outbound_blocking.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_60_correlation.conf
Include /usr/local/apache/conf/base_rules/modsecurity_localrules.conf
#Include /usr/local/apache/conf/more_rules/00_asl_rbl.conf
#Include /usr/local/apache/conf/more_rules/00_asl_whitelist.conf
Include /usr/local/apache/conf/more_rules/05_asl_exclude.conf
Include /usr/local/apache/conf/more_rules/05_asl_scanner.conf
Include /usr/local/apache/conf/more_rules/10_asl_antimalware.conf
Include /usr/local/apache/conf/more_rules/10_asl_rules.conf
Include /usr/local/apache/conf/more_rules/11_asl_data_loss.conf
Include /usr/local/apache/conf/more_rules/20_asl_useragents.conf
Include /usr/local/apache/conf/more_rules/30_asl_antimalware.conf
Include /usr/local/apache/conf/more_rules/30_asl_antispam.conf
Include /usr/local/apache/conf/more_rules/30_asl_antispam_referrer.conf
Include /usr/local/apache/conf/more_rules/40_asl_apache2-rules.conf
Include /usr/local/apache/conf/more_rules/50_asl_rootkits.conf
Include /usr/local/apache/conf/more_rules/60_asl_recons.conf
Include /usr/local/apache/conf/more_rules/99_asl_exclude.conf
Include /usr/local/apache/conf/more_rules/99_asl_jitp.conf
Include /usr/local/apache/conf/more_rules/trusted-domains.conf
Salir y Guardar el archivo
Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:
/usr/sbin/httpd -t
Si todo está bien mostrará “Syntax OK”.
Ahora debemos re-arrancar al apache:
service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)
Para verificar que todo esta OK podemos ejecutar:
tail -f /usr/local/apache/logs/error_log
Esto debe mostrar algo como:
[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
Enlaces a Recursos:
http://www.modsecurity.org/
http://www.cyberciti.biz/faq/rhel-fedora-centos-linux-enable-epel-repo/
http://www.isecauditors.com/es/iseclab4.html#Capitulo4
http://www.infosecwriters.com/text_resources/pdf/Defending-web-services.pdf
http://www.securityfocus.com/infocus/1739
http://www.securityfocus.com/columnists/418
Lynx es un navegador de internet en formato de texto que podría ser usado para realizar hackeos, por ello es conveniente cambiar el permiso de ejecución de lynx ubicado en:
/usr/bin/lynx y pasarlo a 600 ó cambiarlo a 750 y cambiarle el grupo a Wheel de tal forma que sólo pueda ser ejecutado por los usuarios en dicho grupo, los comandos son:
chmod 600 /usr/bin/lynx
chown root:wheel /usr/bin/lynx
Para conocer el contenido del archivo de registro de eventos (log) de los emails manejados por exim ejecutamos:
tail -f /var/log/exim_mainlog
Este archivo nos muestra el directorio desde el cual se emiten los emails. Ahora bien, para mejorar la información reportada podemos modificar el archivo de configuración del exim. Esto lo podemos hacer por SSH ó por WHM según lo que se prefiera:
Por SSH:
nano /etc/exim.conf
Debemos buscar el parámetro log_selector y colocar:
log_selector = +address_rewrite +all_parents +arguments +connection_reject +delay_delivery +delivery_size +dnslist_defer +incoming_interface +incoming_port +lost_incoming_connection +queue_run +received_sender +received_recipients +retry_defer +sender_on_delivery +size_reject +skip_delivery +smtp_confirmation +smtp_connection +smtp_protocol_error +smtp_syntax_error +subject +tls_cipher +tls_peerdn
Salir y guardar el arhivo.
Finalmente debemos reiniciar el exim con:
/etc/init.d/exim restart
Por WHM:
WHM > Service Configuration > Exim Configuration Editor > Advanced Editor
Colocar en la primera caja de ingreso de texto (textarea) lo siguiente:
log_selector = +address_rewrite +all_parents +arguments +connection_reject +delay_delivery +delivery_size +dnslist_defer +incoming_interface +incoming_port +lost_incoming_connection +queue_run +received_sender +received_recipients +retry_defer +sender_on_delivery +size_reject +skip_delivery +smtp_confirmation +smtp_connection +smtp_protocol_error +smtp_syntax_error +subject +tls_cipher +tls_peerdn
Luego hacer clic en el botón Save y esperar que el WHM guarde y reinicie el Exim. LISTO
OPCIONAL: Hace falta realizar pruebas.
PHP y Apache no hacen seguimiento de los usuarios que envían correos a través del usuario nobody (usuario estándar de PHP), causando debilidades en el uso de formmail y la posibilidad de no poder detectar usuarios malintencionados que envían spam.
Revisar el exim_mainlog no es de gran ayuda, se ve la salida del correo electrónico, pero no se puede hacer seguimiento de qué usuario o secuencia de comandos lo envió.
Si se analiza el archivo php.ini notamos que el programa de correo electrónico está establecido en: /usr/sbin/sendmail y el 99,99 % de los scripts PHP sólo utilizarán la función mail () por lo que todo irá a través de la /usr/sbin/sendmail.
Para poder disponer de un registro de eventos de emails enviados usando nobody debemos realizar el siguiente procedimiento:
Ingresar en la consola con el usuario root y apagar el servicio exim mientras se completa este procedimiento:
/etc/init.d/exim stop
Respaldar el archivo original /usr/sbin/sendmail :
mv /usr/sbin/sendmail /usr/sbin/sendmail.hidden
Crear el script de monitoreo de SPAM para el nuevo sendmail:
nano /usr/sbin/sendmail
Colocar en el archivo lo siguiente:
#!/usr/local/bin/perl
# use strict;
use Env;
my $date = `date`;
chomp $date;
open (INFO, ">>/var/log/spam_log") || die "Failed to open file ::$!";
my $uid = $>;
my @info = getpwuid($uid);
if($REMOTE_ADDR) {
print INFO "$date - $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME n";
}
else {
print INFO "$date - $PWD - @infon";
}
my $mailprog = '/usr/sbin/sendmail.hidden';
foreach (@ARGV) {
$arg="$arg" . " $_";
}
open (MAIL,"|$mailprog $arg") || die "cannot open $mailprog: $!n";
while (<stdin> ) {
print MAIL;
}
close (INFO);
close (MAIL);</stdin>
Salir y Guardar.
Debemos cambiar los permisos de ejecución de sendmail
chmod +x /usr/sbin/sendmail
Creamos un nuevo archivo log para guardar el histórico de todos los correos emitidos desde el servidor utilizando programas web:
touch /var/log/spam_log
chmod 0777 /var/log/spam_log
Volvemos a arrancar el EXIM:
/etc/init.d/exim start
Podemos entonces monitorear el archivo spam_log para ubicar el spam. Es posible usar cualquier aplicación de formmail o un script que use la función mail() de php.
tail - f /var/log/spam_log
Un ejemplo de lo guardado en el histórico sería:
Mon Apr 11 07:12:21 EDT 2005 - /home/usuario/public_html/directorio/subdirectorio - nobody x 99 99 Nobody / /sbin/nologin
El archivo spam_log no se ha inicializado para ser rotado por lo que podría llegar a ser muy grande rápidamente. Debe entonces ser agregado logrotation, para ello debemos editar el archivo de configuración del mismo:
nano /etc/logrotate.conf
Buscar:
# no packages own wtmp -- we'll rotate them here
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
Y agregar debajo de eso:
# SPAM LOG rotation
/var/log/spam_log {
monthly
create 0777 root root
rotate 1
}
También podríamos querer evitar que nuestro sendmail sea sobre-escrito para lo cual podemos ejecutar:
chattr + i /usr/sbin/sendmail
OBSOLETO: Es preferible no instalar el webmin en los servidores de producción y lo indicado aquí puede hacerse directamente con crontab -e (ver lo explicado en el punto del RKHunter).
Con la finalidad de que todas las madrugadas se ejecuten los programas de diagnóstico y se emitan los emails al Administrador del Servidor debemos:
Ingresar a:
Webmin > Sistema > Tareas Planificadas (Cron)
Crear los siguientes crones usando el enlace “Crear una nueva tarea de cron en catálogo“ y asignándolos a root, con ejecución en cualquier fecha a las horas seleccionadas, todos los días de todas las semanas de todos los meses:
Ejecutar a las 12:10 AM:
/usr/local/bin/rkhunter --update > /dev/null 2>&1
Ingresar a:
WHM > Service Configuration > Apache Configuration > Global Configuration
Y cambiar los siguientes parámetros:
SSLCipherSuite ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
TraceEnable Pasarlo de On a Off
ServerSignature Pasarlo de On a Off
ServerTokens Pasarlo de Full a ProductOnly
FileETag Pasarlo de All a None
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 256
MaxClients 150
MaxRequestsPerChild 10000
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100
TimeOut 300
Luego se debe hacer clic en el botón “Save” y finalmente hacer clic en el botón “Rebuild configuration and restart apache“.
A su vez, esto se puede hacer manualmente de la siguiente forma:
Uno de los mecanismos comúnmente usados por los intrusos es verificar la versión del servidor web Apache con la finalidad de conocer con exactitud cual tipo de vulnerabilidad o exploit será utilizada para penetrar el sistema. Para aumentar la seguridad debemos deshabilitar la identificación del Apache con:
nano /etc/httpd/conf/httpd.conf
Buscar y asegurar que las siguientes variables se cumplan:
Timeout 300
TraceEnable Off
ServerSignature Off
ServerTokens ProductOnly
FileETag None
StartServers 5
<ifmodule prefork="" c="">
MinSpareServers 5
MaxSpareServers 10
</ifmodule>
ServerLimit 256
MaxClients 150
MaxRequestsPerChild 10000
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100
Reiniciar Apache:
service httpd restart (ó con /etc/rc.d/init.d/httpd restart)
Por otra parte, si se quiere limitar la exposición de la versión de PHP que se está ejecutando se debe hacer lo siguiente:
WHM > Service Configuration > PHP Configuration Editor
Buscar:
expose_php
y colocarlo en Off. Luego hacer clic en el botón “Save“.
Si se desea hacer esto manualmente se deben editar los archivos php.ini siguientes:
nano -w /etc/php.ini
nano -w /usr/local/lib/php.ini
nano -w /usr/local/php4/lib/php.ini
Buscar la opción
expose_php
y colocarla en Off
Guardar el archivo y rearrancar el apache
service httpd restart (ó con /etc/rc.d/init.d/httpd restart)
LISTO.
Para mantener la seguridad es importante que la contraseña de root sea cambiada periódicamente. Esto se logra ejecutando el comando:
passwd
Solicitará la contraseña nueva dos veces y listo.
Ingresar a:
WHM > Service Configuration > Apache Configuration > Global Configuration
Y cambiar los siguientes parámetros:
SSLCipherSuite ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
TraceEnable Pasarlo de On a Off
ServerSignature Pasarlo de On a Off
ServerTokens Pasarlo de Full a ProductOnly
FileETag Pasarlo de All a None
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 256
MaxClients 150
MaxRequestsPerChild 10000
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100
TimeOut 300
Luego se debe hacer clic en el botón “Save” y finalmente hacer clic en el botón “Rebuild configuration and restart apache“.
A su vez, esto se puede hacer manualmente de la siguiente forma:
Uno de los mecanismos comúnmente usados por los intrusos es verificar la versión del servidor web Apache con la finalidad de conocer con exactitud cual tipo de vulnerabilidad o exploit será utilizada para penetrar el sistema. Para aumentar la seguridad debemos deshabilitar la identificación del Apache con:
nano /etc/httpd/conf/httpd.conf
Buscar y asegurar que las siguientes variables se cumplan:
Timeout 300
TraceEnable Off
ServerSignature Off
ServerTokens ProductOnly
FileETag None
StartServers 5
<ifmodule prefork="" c="">
MinSpareServers 5
MaxSpareServers 10
</ifmodule>
ServerLimit 256
MaxClients 150
MaxRequestsPerChild 10000
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100
Reiniciar Apache:
service httpd restart (ó con /etc/rc.d/init.d/httpd restart)
Por otra parte, si se quiere limitar la exposición de la versión de PHP que se está ejecutando se debe hacer lo siguiente:
WHM > Service Configuration > PHP Configuration Editor
Buscar:
expose_php
y colocarlo en Off. Luego hacer clic en el botón “Save“.
Si se desea hacer esto manualmente se deben editar los archivos php.ini siguientes:
nano -w /etc/php.ini
nano -w /usr/local/lib/php.ini
nano -w /usr/local/php4/lib/php.ini
Buscar la opción
expose_php
y colocarla en Off
Guardar el archivo y rearrancar el apache
service httpd restart (ó con /etc/rc.d/init.d/httpd restart)
LISTO.
El comando telnet es una de las vías más vulnerables para permitir el acceso a intrusos en forma remota, es por ello que debemos deshabilitarlo. Para lograr esto se debe ejecutar:
nano -w /etc/xinetd.d/telnet
Colocar:
disable = yes
Salir y Guardar
Reiniciar con:
/etc/init.d/xinetd restart
