1. En tu cortafuegos (tienes uno, ¿verdad?) confirma que el puerto MySQL para entrantes es el 3306 y ciérralo. Si este puerto se queda abierto se expone tanto a un abuso de servicio y una amenaza de seguridad ya que no sólo los hackers pueden irrumpir en MySQL, sino que cualquier usuario puede almacenar su base SQL en tu servidor y acceder desde cualquier equipo, y así (ab)usar los recursos de tu servidor.
2. Chequea los permisos de /tmp. Deberían estar en chmod 1777
3. Chequea el propietario de /tmp. Debería pertenecer a root:root
4. Chequea /etc/cron.daily/logrotate. Debido a un bug en logrotate, si se monta /tmp con la opción noexec, necesitas que logrotate use un directorio temporal diferente. Si no lo haces, este syslog puede no reiniciarse correctamente y escribirá sobre archivos antiguos/incorrectos.
5. Chequea los permisos de /var/tmp. Debería estar en chmod 1777
6. Chequea el propietario de /var/tmp. Debería pertenecer a root:root
7. Chequea que /var/tmp está montado como sistema de archivos. No debería estar enlazado (ln -s) a /tmp o montado como un sistema de archivos.
8. Chequea que /var/tmp está montado con noexec,nosuid. Normalmente no tiene estas opciones, con lo que deberías considerar agregar un punto de montaje en /etc/fstab con esas opciones.
9. Chequea los permisos de /usr/tmp. Deberia estar en chmod 1777
10. Chequea el propietario de /usr/tmp. Deberia pertenecer a root:root
11. Chequea que /usr/tmp está montado como sistema de archivos o es un enlace simbólico (ln -s) de /tmp.
12. Chequea /etc/resolv.conf . No deberías especificar como nombre de servidor (nameserver) a 127.0.0.1 o a localhost. Usa la IP principal de los servidores en su lugar. Chequea
12b. Chequea /etc/named.conf por las restricciones de recursividad . Si tienes un servidor DNS local ejecutándose pero no tienes restricciones de recursividad establecidas, es un riesgo de seguridad y de rendimiento tan buenos como ataques DDoS contra tu sistema, con lo que deberías establecerlo sólo para las direcciones IP locales.
13. Chequea el runlevel del servidor. Para un entorno seguro deberías ejecutar el servidor sólo a nivel 3. Puedes solucinarlo editando /etc/inittab y cambiando la linea de “initdefault” a como sigue: id:3:initdefault y luego reiniciar el servidor.
14. Chequea el cron del usuario “nobody”. Tienes un registro de nobody que deberías chequear si no ha sido creado por un exploit.
15. Chequea el soporte del Sistema Operativo. Asegírante que tu versión aún tiene soporte del fabricante y que las actualizaciones aún siguen disponibles.
16. Chequea si SSHv1 está desactivado. Deberías, editando /etc/ssh/sshd:config y configurando: Protocol 2 (eliminando la almohadilla del principio de linea y editando donde pone “1.1″)
17. Chequea si SSH está en un puerto no-estándar. Mover SSH a un puerto no-estándar evita escaneos básicos de puertos SSH. Edita /etc/ssh/sshd_config y configura Port nnnn, donde nnnn es un puerto a tu elección. ¡No olvides abrir el puerto en el cortafuegos antes!
18. Chequea en SSH “PasswordAuthentication”. Para la seguridad definitiva de SSH, puedes considerar desactivar esta opción y permitir acceso sólo usando “PubKeyAuthentication”.
19. Chequea que el puerto 23 de telnet no está en uso. Cierra este puerto en tu cortafuegos. Telnet es un protocolo inseguro y deberías desactivar el servicio telnet si está ejecutándose.
20. Chequea los límites de recursos de la shell. Deberías activarlos para prevenir que los usuarios de shell consuman recursos de servidor (exploits de DoS, mayormente). Si estás usando cPanel/WHM activa “Shell Fork Bomb Protection”.
21. Desactiva todas las instancias de IRC - BitchX, bnc, eggdrop, sniffers genéricos, servicios guardianes, ircd, psyBNC, ptlink. Si estás usando WHM puedes hacerlo en “Background Process Killer”.
22. Chequea el modulo mod_security en apache. Debería estar instalado.
23. Chequea el modulo mod_evasive en apache- Deberías instalarlo desde el código fuente para evitar ataques DoS contra apache. Cuidado porque este módulo se carga la funcionalidad de FrontPage.
24. Chequea el valor RLimitCPU de apache. Deberías establecer un valor para evitar scripts que consuman recursos de servidor (exploits de DoS).
25. Igualmente para el valor RLimitMEM.
26. Chequea el valor de enable_dl en php. Deberías modificar /usr/local/lib/php.ini y configurar enable_dl = off. Esto previene a los usuarios de ejecutar modulos php que afecten a cualquiera en el servidor. Nota que si se usan librerías dinámicas, como ioncube, deberás cargarlas directamente en php.ini
27. Chequea el valor de disable_functions en php. Deberías modificar /usr/local/lib/php.ini y desactivar las funciones más comúnmente atacadas. Por ejemplo:disable_functions = show_resource, system, shell_exec, passthru, exec, phpinfo, popen, proc_open. Algunos scripts de clientes web pueden fallar con algunas de estas funciones desactivadas, así que tendrás que quitarlas de esta lista.
28. Chequea phpsuexec. Para reducir el riesgo de que hackers accedan a todos los sitios del servidor desde un script web, deberías activar phpsuexec cuando construyes apache/php. Nota que hay efectos laterales cuando se activa phpsuexec en un servidor y debes tenerlos en cuenta antes de activarlos.
Traducción libre de http://kevin.hatfieldfamilysite.com/?p=147:
Fuente: http://www.albianlinux.com/davidp/
Domain Name System (DNS)
La funcionalidad del servicio de DNS es convertir nombres de máquinas (legibles y fáciles de recordar por los usuarios) en direcciones IP o viceversa.
Ejemplo:
A la consulta de cuál es el IP de pirulo.remix.com, el servidor responderá 192.168.0.1 (esta acción es conocida como mapping); del mismo modo, cuando se le proporcione la dirección IP, responderá con el nombre de la máquina (conocido como reverse mapping).
El Domain Name System (DNS) es una arquitectura arborescente para evitar duplicación de la información y facilitar la búsqueda. Por ello, un único DNS no tiene sentido sino como parte del árbol.
La aplicación que presta este servicio se llama named, se incluye en la mayoría de distribuciones de GNU/Linux (/usr/sbin/named) y forma parte de un paquete llamado bind coordinado por ISC (Internet Software Consortium). DNS es simplemente una base de datos, por lo cual es necesario que las personas que la modifiquen conozcan su estructura, ya que, de lo contrario el servicio quedará afectado. Como precaución, debe tenerse especial cuidado en guardar las copias de los archivos para evitar cualquier interrupción en el servicio.
Un proxy-caché recibe peticiones de objetos por parte de los clientes (en este caso navegadores web) y las reenvía al servidor. Cuando recibe los objetos solicitados del servidor, los envía al cliente y almacena una copia de los mismos en un caché de disco.
La ventaja del caching consiste en que cuando varios clientes solicitan el mismo objeto, este puede proporcionárseles desde el caché de disco. De este modo, los clientes obtiene los datos mucho más rápidamente que si lo hicieran desde Internet y se reduce al mismo tiempo el volumen de transferencias en red.
Este es un tema que aparentemente no tiene nada que ver con la programación de computadores, pero es fundamental conocer ciertos conceptos para poder desarrollar aplicaciones sobre ciertas tecnologías. Y aún más sabiendo que la programación forma importante parte del Internet.Un servidor Web es un software de aplicación que nos vindra un servicio; pero ¿qué tipo de servicio? bien, al decir “Web” nos referimos obviamente a internet o a una red, por ello un “Servidor Web” debe implementar el protocolo HTTP (protocolo de transferencia de hipertexto). Este protocolo está diseñado para transferir páginas web, es decir, documentos en HTML (HyperText Markup Language): textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de sonidos.
Aclaremos algo
El termino servidor es algo ambiguo, ya que un servidor es el software que presta un servicio, pero también se llama servidor a la máquina donde está instalado dicho software. En este artículo vamos a hablar del software, mas no del hardware.
¿Cómo funciona?
El servidor está siempre a la espera de peticiones Web. Dichas peticiones son hechas por un cliente http (un navegador web), que después de realizar la petición espera la respuesta del servidor. Por ejemplo, cuando digitas en tu navegador la dirección http://www.google.com/ este envía una petición HTTP al servidor de Google, dicho servidor responde al cliente enviando el código HTML de dicha página. El cliente recibe el código fuente, lo interpreta y lo muestra en pantalla. El servidor se limita a recibir las peticiones y responderlas adecuadamente, mientras el cliente se encarga del proceso de interpretación.
En cuanto a programación se refiere, existen dos tipos de aplicaciones web: del lado del cliente y del lado del servidor. Las aplicaciones del lado del cliente se ejecutan en el navegador web, entre ellas cabe destacar JavaScript, Visual Basic Script y los applets de Java. En cuanto a las aplicaciones del lado del servidor existen lenguajes de programación, que se ejecutan en el equipo servidor, generalmente formando documentos HTML dinámicos (basandose en operaciones y/o acceso a bases de datos, por ejemplo). Entre los lenguajes más destacables del lado del servidor están: PHP, JSP, ASP, Perl, CGI, entre otros.
En la mayoría de los casos se opta por utilizar tecnologías del lado del servidor, por varios motivos, por ejemplo: al ejecutarse en el servidor las respuestas son, por lo general, estándares XHTML por lo que cualquier navegador puede interpretarlas, cosa que no pasa con las tecnologías cliente (que en algunos casos necesitan plugins). Otra ventaja es ?a seguridad: al ejecutarse el código fuente en el servidor, el programación es transparente al cliente, permitiendo ocultar así los detalles de implementación.
¿Qué servidores existen?
Algunos servidores conocidos son: